第一輪 UAT 結束後，規則確認、修正、重驗和第二輪測試資料準備，全部要放進這五個工作天。
Day 22 收到的回饋有大有小：單據無法結案會直接卡住流程，專案沒有帶入使用者會影響資料，流程視覺化和單據分類需要補功能，icon 去背則被不同使用者重複提出。
五天放不下所有想做的事。我先決定修正順序，再安排 Agent。
分類是工作種類。
程式缺陷交給 frontend-agent 或 api-integration-agent；新功能先找流程負責人確認，再交給 frontend-agent；權限與資料可見範圍要讓 security-agent 提早加入；畫面文字和文件則由 frontend-agent、documentation-agent 處理。
優先級是時間順序。
單據無法結案和 icon 去背都可能動到前端，前者會讓核心流程停住，所以先處理。流程視覺化影響很多角色，狀態映射尚未確認時，先由流程負責人把規則說清楚。
分類解決分工，優先級控制五天內的版本範圍。
每一則回饋進入排序前，我會看四件事。
| 判斷面向 | 我會確認什麼 |
|---|---|
| 流程阻斷 | 申請、審核、執行或結案是否會停住 |
| 資料與權限 | 是否送出錯誤資料、帶錯對象或產生越權風險 |
| 影響範圍 | 影響哪些角色、多久遇到一次、是否被多人提出 |
| 修改與重驗成本 | 要動幾個檔案、是否跨 API、要重跑多少情境 |
流程阻斷與資料風險先判斷。風險相近時，再看影響人數、修改範圍和重驗成本。
五天結束時，核心流程要能安全地交給第二輪 UAT。
單據最後無法結案、專案沒有帶入相關使用者，都會讓流程中斷或資料不完整。
這些項目立即重現、立即修正，原本失敗的情境也要在同一天重跑。
互斥選項、單據流程視覺化和單據分類會影響日常操作。
互斥規則已經清楚，可以直接修。流程視覺化要先確認狀態映射；單據分類要先限制頁籤、統計與既有 API 的修改範圍。規則與邊界確認後，才進入這一輪。
icon 去背對流程影響較低，被多人重複提出後，可見度已經升高。
這類項目適合和 favicon、文件入口或同一個畫面的文字調整放在一起，減少 Agent 重複讀取相同檔案。
一張申請單同時建立多個 repository，需要擴充既有自動化，當時的使用情境也比較少。
我把它留在後續清單，記錄延後理由與重啟條件。等需求量增加、自動化補齊或下一版重新排程時，再拿回來評估。
| 回饋 | 阻斷／風險 | 影響範圍 | 修改與重驗 | 優先級 | 本輪決策 |
|---|---|---|---|---|---|
| 結案回傳 500 | 核心流程阻斷 | 申請人、執行人 | 中 | P0 | 立即修正 |
| 專案未帶入使用者 | 資料可能不完整 | 專案申請人 | 中 | P0 | 立即修正 |
| 互斥選項同時成立 | 申請內容不合理 | 雲端資源申請人 | 小 | P1 | 本輪修正 |
| 流程視覺化 | 跨角色理解 | 超過一種角色 | 中 | P1 | 規則確認後處理 |
| 單據分類與頁籤 | 高頻尋找成本 | 申請人、處理人 | 中 | P1 | 限制範圍後處理 |
| icon 去背 | 視覺干擾 | 多位使用者重複提出 | 小 | P2 | 併入小批次 |
| 一張單建立多個 repo | 需擴充自動化 | 使用情境較少 | 大 | P3 | 本輪延後 |
這張 UAT Priority Board 讓每一個決定都有原因。有人追問某項功能的進度時，我可以直接說明它卡在規則、容量，或正在等待原情境重驗。
時間有限時，我會先把驗證時間保留下來，再安排能做多少開發。
| 時間 | 工作 | 主要投入 |
|---|---|---|
| 第 1 天 | 重現 P0、確認 P1 規則、凍結本輪範圍 | 我、流程負責人、qa-agent、security-agent |
| 第 2–3 天 | 依檔案邊界平行修正 P0／P1，小項目併批 | frontend-agent、api-integration-agent、指揮中心 |
| 第 4 天 | 用原始 UAT 情境重驗，失敗項退回修正 | qa-agent、我、對應 Agent |
| 第 5 天 | 核心回歸、文件同步、準備第二輪帳號與資料 | qa-agent、documentation-agent、我 |
實作只占兩個主要工作天。這個安排會主動限制需求量，也能保住重驗和第二輪準備。
如果第 3 天還有 P0 未完成，P2 就離開本輪。P1 的規則到第 1 天結束仍未確認，也先移到下一輪。這兩條線讓 Agent 不會在等待決策時消耗開發時間。
我會把 Agent 放到當下的瓶頸。
frontend-agent 通常承接最多畫面與狀態修改。遇到資料帶入或 API 合約問題時，api-integration-agent 才加入。qa-agent 從第 1 天就開始把原回饋改成可重跑情境，提早準備第 4 天的驗證。
security-agent 優先看權限、資料可見範圍與輸入風險。documentation-agent 等行為和文字穩定後集中更新文件，減少同一段內容反覆修改。
指揮中心負責讀取異動檔案與相依關係，安排哪些工作可以平行。產品優先順序、規則答案和五天容量由我決定。
# UAT Priority Board
| ID | 原始回饋 | 類型 | 阻斷／資料風險 | 影響角色／頻率 | 修改範圍 | 重驗成本 | 優先級 | 本輪決策 | 負責人 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| F-01 | | | | | | | P0／P1／P2／P3 | 修正／確認／批次／延後 | |
先放入 P0，再看 P1 能否在第 3 天前完成。第 4、5 天保留給重驗與第二輪準備。
Day 22 讓我看到真實使用者會在哪裡停下來。Day 23 往前一步，把有限時間放到風險最高、影響最大的地方。
這次我先留下驗證時間，再決定開發量。五個 Agent 集中到當下的瓶頸。
優先順序排好後，下一步要把 P0、P1 和可併批的 P2 轉成明確任務，交給指揮中心安排執行順序。
Day 24，我會把這張優先矩陣轉成 Agent 可以直接執行的工作清單。
iThome鐵人賽
看影片追技術